Designing and Optimizing Storage in an Exchange Server 2007 Environment (part 4)

1/14/2012 4:08:18 PM

SAN or NAS disks are generally much more expensive than the disks used in DAS. As such, you will generally utilize the SAN/NAS storage only where it makes a significant difference in performance. Many aspects of Exchange 2007 utilize the disks but use them in different ways.

The largest consumer of disk performance is the Mailbox role. In Exchange 2007, it is very common to run servers that are dedicated to doing nothing but hosting mailboxes. On these systems, several different consumers of disk resources would benefit from being placed on SAN or NAS, as discussed in the following sections.

Storage of Transaction Log Files (.log Files)

Changes made to the database are first committed to the transaction log. This results in a sequential write to the disk. Because sequential I/O is significantly higher per disk than random I/O, the logs do not benefit as much from being placed on SAN or NAS disks. For performance reasons as well as recoverability reasons, the logs should not be located on the same disks as the database. Similarly, the logs should not be on the same disk as the page file for the operating system.

To create a storage group with log files on a NAS or SAN disk, complete the following steps:

1.	From the Start menu, select Programs, Microsoft Exchange, Exchange Management Console.
2.	Expand Server Configuration, and then highlight Mailbox.
3.	Right-click the Mailbox server, and choose New Storage Group on the shortcut menu.
4.	Enter the storage group name in the Storage Group Name field.
5.	Next to the Log Files Location field, click Browse.
6.	Navigate to the drive letter representing the SAN/NAS disk, and click OK.
7.	Next to the System Files Location field, click Browse.
8.	Navigate to the drive letter representing the SAN/NAS disk, and click OK.
9.	Click New to create a new storage group similar to the one shown in Figure 1. Figure 1. New Storage Group Wizard.
10.	After the wizard has completed, click Finish.

Storage of the JET Database (.edb File)

The Exchange 2007 Mailbox server stores all mail in a JET database. Unlike Exchange Server 2003, there is no longer a .stm file. The JET database is randomly accessed as users access their mail or send and receive new messages. For purposes of performance and recoverability, the disks that contain the databases should be physically separate from the disks that contain the logs.

To create a mailbox database with the files stored on a NAS/SAN disk, perform the following steps:

1.	From the Start menu, select Programs, Microsoft Exchange, Exchange Management Console.
2.	Expand Server Configuration, and then highlight Mailbox.
3.	Right-click the storage group that will host the database, and choose New Mailbox Database on the shortcut menu.
4.	Enter the name for the new mailbox database in the Mailbox Database Name field.
5.	Next to the Exchange Database File Path field, click Browse.
6.	Navigate and highlight the drive letter that represents the SAN/NAS disk.
7.	Click New to create a new mailbox similar to the one shown in Figure 2. Figure 2. New Mailbox Database Wizard.
8.	When the wizard is completed, click Finish.

Performing Content Indexing

The Search features have been significantly improved in Exchange 2007. Content indexing is a random access workload that should be placed on the same LUN as the database that it is indexing. Content indexing is usually about 5% of the database size. Content indexing runs in the background indexing messages as they arrive and, as such, the disk I/O impact is minimal.

To create a content index on a database that is SAN or NAS attached, perform the following:

1.	From the Start menu, click Programs, Microsoft Exchange, Exchange Management Shell.
2.	From the Exchange Management Shell, type: New-ContentIndex -Database <databaseIDParameter> -Directory <string> where databaseIDParameter is the mailbox database that will be indexed and the Directory <string> is the path to the location of the index. By default, this is created in the same path as the database.
3.	Press Enter.

When a process requests a page from memory and the system cannot find the page at the requested location, a page fault occurs. If the page is elsewhere in memory, the fault is a soft page fault. If the page must be retrieved from disk, the fault is a hard page fault. Most processors can handle large numbers of soft page faults without consequence. However, hard page faults can cause significant delays. Continuous high rates of disk paging indicate a memory shortage. If memory can not be increased sufficiently to reduce the number of hard page faults, you must improve the speed of the disks that host the page file. In this scenario, the page file location could benefit from the improved performance of a SAN or NAS disk.

If you want to move your page file to a SAN or NAS attached disk, perform the following steps:

1.	Right-click My Computer and select Properties on the shortcut menu.
2.	Click the Advanced tab.
3.	In the Performance section, click Settings.
4.	From the Performance Options pane, click the Advanced tab.
5.	Near the bottom of the pane in the Virtual Memory section, click Change.
6.	Highlight the drive letter that represents the disk that should host the page file.
7.	Click the Custom Size option button.
8.	Enter an initial size of 1.5*system memory.
9.	Enter a maximum size of 1.5*system memory, and then click Set.
10.	Highlight the drive letter that previously held the page file.
11.	Click the No Paging File option button, and then click Set.
12.	Click Yes to accept the warning about the page file on the volume you are modifying, and then click OK.
13.	Click OK again to accept the notification that you need to reboot for the settings to take effect.
14.	Click OK twice to close the dialog box.
15.	Click Yes to reboot if it is acceptable to reboot the system.

You might wonder why the page file was configured with the same value for initial and maximum sizes. By setting the range to a single value, the page file is initially created at a size that will never change. This allows the page file to be contiguous on the drive. A page file that is allowed to grow might grow to a new location on the hard drive. This results in fragmentation of the page file and causes a reduction in page file performance.

In Exchange 2007, significant improvements have been achieved in memory management because of the use of 64-bit code. This allows you to install enough memory to greatly reduce the need for the system to page to disk.

Content Conversion

Most content conversion performed in an Exchange 2007 environment is performed by the client access servers (CASs) and the Hub Transport servers. Legacy WebDAV content conversion, for legacy Outlook Web Access (OWA) clients, occurs on the Exchange 2003 Mailbox server. When a client needs data that must be converted on a CAS, the data is pulled from the Exchange 2003 Mailbox server, converted in the Exchange 2007 Mailbox server’s TMP folder, and sent to the CAS. To improve performance, the TMP folder should not be on the same LUN as the page file and operating system. If there is a large amount of legacy OWA clients supported, placement of the TMP folder on a NAS or SAN disk might result in improved performance.

Performing Database Maintenance

The Exchange 2007 Information Store performs periodic online maintenance against each database. The two tasks that impact disk I/O are the hard deletion of messages and mailboxes that are past their retention policy and online database defragmentation. Because a backup job will halt online defragmentation, you must be sure to give both database maintenance and backup jobs exclusive windows of time to finish their tasks or disk contention will result in greatly reduced performance for both tasks. If you are unable to sufficiently separate these two events, the increased I/O load would benefit from the databases being located on SAN or NAS disks.

Backing Up and Restoring Data

Backing up data requires that data be read from both the database and transaction log volumes. This additional I/O can impact user response times and should be avoided during business hours. Placing the databases and log files on faster SAN or NAS disks can often result in faster backup and restore processes, assuming the destination location for the data is not the bottleneck. Backups that attach to the SAN or NAS directly are usually much faster than backing up Exchange 2007 via the network with an Exchange agent.

The process of performing a soft recovery in the case of a database restore requires that the JET engine play back all of the transaction log files. This results in a sequential read stream from the disks containing the associated log files. As a result, the recovery process will be faster if the transaction log files are on a disk with fast sequential disk access, such as SAN or NAS.

In addition to having similar needs for content conversion and paging, CASs also consume disk I/O in the process of protocol logging.

Enabling Protocol Logging

Protocol logging, if enabled, results in a sequential write that is a performance hit and consumes disk space to store the logs. Protocol logging is typically used to verify the performance of a given protocol or when you suspect attacks from the Internet.

Impact from Message Tracking Logs

Edge and Hub Transport servers maintain message tracking logs that result in sequential write traffic for the log files. Because sequential write performance is much higher than random access, these types of logs typically don’t require high-performance disks.

Conversion of Incoming Mail

The Hub Transport server converts incoming mail into a Messaging Application Programming Interface (MAPI) format. This occurs in the TMP directory of the Hub Transport server. As such, it is important to ensure that the TMP directory is not located on the same LUN as the page file or the operating system. In environments that receive very large amounts of Internet mail, it is beneficial to place this TMP directory on a SAN or NAS attached disk.

Events Trigged by Agents

Customization of the Transport server is done via bits of code more commonly referred to as agents. These agents run in the common language runtime environment and are triggered by specific events. Some agents write data to a log, which could result in a disk performance hit in addition to consuming disk space. If you find your environment taking performance hits because of agents, consider configuring them to place their logs on higher-performance NAS or SAN disks.